모드 (인터페이스)

(사용자 인터페이스에서의) 모드.

Definitions

Larry Tesler:1

In a 1981 article about Smalltalk,2 I defined a mode as “a state of the user interface that lasts for a period of time, is not associated with any particular object, and has no role other than to place an interpretation on operator input.”

Jef Raskin:3

A human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user’s locus of attention and (2) the interface will execute one among several different possible responses to the gesture, depending on the system’s current state….

If the definition of a mode is based exclusively on the design of the interface, as our definition has been up to now, all users would make the same errors, albeit with different frequencies. They do not. A given interface feature can be modal for one user and not modal for another. A more complete definition of modes must incorporate how the user views the interface.

Mode-related problems in command language

Three properties of a command language that cause mode-related problems:1

  • Verbs precede their objects: The most frequently used commands in many interactive systems involve a verb and one object. If the language has any consistency at all, there is prevalent command syntax, which is usually either prefix or suffix. The distinction is whether the user specifies the verb before or after its object. Suffix syntax has a usability advantage: When the user specifies the verb last, its object has already been specified, and the command can be executed immediately. Systems that use prefix syntax must enter a mode to wait for the user to specify the object. Keeping track of mode changes can distract a user from the task at hand.
  • Key meanings are mode-dependent: Languages that use unmodified letter keys to do anything but enter those letters as text need at least two modes: text and command. If unmodified letter keys are typed in command mode but the user thinks the system is in text mode, unintended and sometimes disastrous results ensue.
  • Mode escapes are inconsistent: Users often get “stuck” in a mode. An oft-heard question is, “How do I get out of this mode?”

Discussions on modeless-editing based on Cut/Copy-Paste[1]

Objection 1. User mistakes

After performing a cut, the user might forget that important text was in what we now call the clipboard. She could lose it by cutting or copying something else without an intervening paste or undo.

  • Response: The ability to do other things between cut and paste entails more benefits than risks.
  • Response: A suitable undoing or versioning facility will allow recovery of accidentally deleted data.

Objection 2. Implementation cost

When the user invokes cut or copy, then closes the source document before specifying the destination, the software has to retain a copy of the cut or copied material in the clipboard along with fonts, graphics, and so on, just in case a subsequent paste required it.

  • Response: This was a major concern from 1975 to 1982 because early personal computers had so little DRAM and disk space. But we knew that Moore’s law would soon provide us with enough memory and processing speed to hold on to most clipboards.
  • Response: It is better to burden the developer than the user. A decade later, I turned this argument into the law of conservation of complexity: Every system has an irreducible amount of complexity; the only question is, who is going to have to deal with it? The user? The application programmer? Or the platform developer?

Objection 3. Speed

If you were to watch an NLS expert edit a document, you’d see his fingers blazing and hear a drumroll of strokes (mouse clicks and key presses). Observe an expert user of a modeless editor and you’ll hear fewer strokes per unit time. Staccato versus legato. Citing Fitts’ law, some NLS advocates claimed a speed advantage and attributed it to less hand motion.

  • Response: Stuart Card and Tom Moran showed that the command syntax of NLS required more strokes than that of Gypsy, sometimes twice as many, and in some cases, more mental preparation time. A 1981 study by Terry Roberts and Moran compared experienced users of Gypsy to experienced users of NLS and six other well-known editors. The authors found that experienced Gypsy users, on average, performed a benchmark set of tasks in less time than users of the other editors and twothirds the time of NLS. Fewer key and button presses were required.

Objection 4: Lack of extensibility

Modes can be removed from text editors, but it is hard to remove the modes from other types of software, such as graphics.

  • Response: In the study cited above, the one measure by which Gypsy trailed other text editors was functionality. But that finding didn’t prove that the modeless model could not be extended, only that it had not been extended. Another decade elapsed before Apple’s Macintosh entered the market and attracted enough applications to prove the model extensible. As for graphics editors, I agree with the common wisdom that modes can be good when they support a metaphor like picking up a brush, and when feedback identifying the current mode is displayed where the user is almost certain to be looking.

See also

Footnotes

  1. A personal history of modeless text editing and cut-copy-paste ↩ ↩2

  2. Tesler, L. The Smalltalk environment. Byte 6, 8 (Aug. 1981), 90-147. ↩

  3. Chapter 3, The humane interface ↩

2024 © ak